La seconde partie de la présentation « Azure Innovations » d'Ignite 2025 par Mark Russinovich, directeur technique d'Azure, a porté sur les logiciels et a examiné plus en détail les plateformes qu'il prévoit que les développeurs utiliseront pour créer des applications natives du cloud. Azure est né en tant qu'environnement Platform-as-a-Service (PaaS), fournissant l'infrastructure nécessaire à vos applications afin que vous n'ayez pas à vous soucier de l'infrastructure, car tout était automatisé et masqué par des API et configuré via un portail web. Au fil des ans, les choses ont évolué et Azure prend désormais en charge les infrastructures virtuelles et une ligne de commande qui vous permet de gérer les applications ainsi que ses propres outils et langage de développement Infrastructure-as-Code (IaC). Malgré tout cela, la vision d'un Azure serverless a été un moteur clé pour bon nombre de ses innovations, de sa plateforme de calcul à la demande Functions à l'environnement de données massives de Fabric, en passant par la plateforme d'orchestration hébergée et évolutive qui sous-tend le microservice Azure Container Instances. Cette vision est essentielle pour bon nombre des nouveaux outils et services dont M. Russinovich a parlé, offrant une plateforme qui permet aux développeurs de se concentrer sur le code. 

Cette approche n'empêche pas Microsoft de travailler sur des fonctionnalités matérielles et infrastructurelles pour Azure ; celles-ci restent essentielles pour de nombreuses charges de travail et sont indispensables pour prendre en charge les nouveaux modèles cloud natifs. Il est important de comprendre ce qui sous-tend les abstractions que nous utilisons, car cela définit les limites de ce que nous pouvons faire avec le code. 

Conteneurs serverless à grande échelle 

L'une des technologies serverless clés d'Azure est Azure Container Instances. ACI peut être considéré comme un moyen de bénéficier de nombreux avantages de Kubernetes sans avoir à gérer et à exécuter un environnement Kubernetes. Il héberge et gère les conteneurs pour vous, en prenant en charge la mise à l'échelle et les cycles de vie des conteneurs. Dans sa présentation sur l'infrastructure, M. Russinovich a expliqué comment les outils de virtualisation directe ont permis de donner aux conteneurs hébergés par ACI l'accès au matériel Azure, tel que les GPU. Microsoft mise beaucoup sur ACI, qu'il utilise pour héberger de nombreux éléments de services clés sur Azure et Microsoft 365. Il s'agit notamment de la prise en charge de Python par Excel, des agents Copilot Actions et des services de déploiement et d'automatisation d'Azure, et de nombreux autres éléments sont en cours de développement ou en cours de migration vers la plateforme. M. Russinovich le décrit comme « le plan officiel pour l'infrastructure interne de Microsoft ». 

Le développement de l'ACI ne se limite pas au niveau de l'infrastructure. Il concerne également les services d'orchestration qui gèrent les conteneurs. L'une des fonctionnalités clés est un outil appelé NGroups, qui définit des flottes d'images de conteneurs standard pouvant être mises à l'échelle et déployées en cas de besoin. Ce modèle prend en charge les pools de secours à mise à l'échelle rapide du service, qui peuvent être déployés en quelques secondes, avec une personnalisation selon les besoins. 

L'ACI devant prendre en charge des opérations multi-locataires, il est nécessaire de partager équitablement les ressources gérées entre les conteneurs. Sinon, un conteneur hostile pourrait facilement s'approprier rapidement toutes les ressources d'un serveur. Cependant, il est toujours nécessaire que les conteneurs d'un abonnement puissent partager les ressources selon les besoins, un modèle que Russinovich appelle « sursouscription de ressources ». Cela est lié à une fonctionnalité qui s'appuie sur les capacités de virtualisation directe ajoutées à Azure : les instances extensibles. Vous pouvez ici définir les valeurs minimales et maximales pour le CPU et la mémoire, et les ajuster en fonction des variations de charge. Alors que les conteneurs ont traditionnellement évolué en horizontal, les instances extensibles peuvent également évoluer en vertical dans la marge disponible sur un serveur. 

Amélioration de la mise en réseau des conteneurs avec Cilium géré 

La mise en réseau des conteneurs, fait l'objet de mises à niveau, avec des améliorations apportées à la prise en charge par Azure de l'eBPF et plus particulièrement des outils d'observabilité et de sécurité du réseau Cilium. Les filtres de paquets Berkeley étendus vous permettent d'intégrer des sondes et des règles dans le noyau en toute sécurité sans affecter les opérations, tant sous Linux que sous Windows. Il s'agit d'un moyen puissant de gérer le réseau dans Kubernetes, où Cilium est devenu un composant important de sa pile de sécurité. Jusqu'à présent, même si Azure offrait une prise en charge approfondie de l'eBPF, vous deviez apporter vos propres outils eBPF et les gérer vous-même, ce qui nécessite une expertise pour fonctionner à grande échelle. Tout le monde n'est pas ingénieur de plateforme Kubernetes, et avec des outils tels qu'AKS qui fournissent un environnement géré pour les applications cloud natives, disposer d'un environnement eBPF géré constitue une mise à niveau importante. L'outil Azure Managed Cilium offre un moyen rapide de bénéficier de cet avantage dans vos applications, en l'utilisant pour le routage hôte et en réduisant considérablement la surcharge liée au réseau basé sur iptables. 

Vous constaterez les améliorations les plus importantes dans le routage de pod à pod avec des messages de petite taille. Cela n'a rien de surprenant : plus le message est petit, plus la surcharge de routage utilisant iptables est importante. Comprendre comment cela peut affecter vos applications peut vous aider à concevoir une meilleure messagerie, et lorsque les petits messages sont livrés trois fois plus rapidement, il vaut la peine d'optimiser les applications pour tirer parti de ces gains de performances. Grâce à l'intégration de Cilium à AKS d'Azure, celui-ci devient désormais le moyen par défaut de gérer le réseau de conteneurs sur un hôte de pod (38 % plus rapide qu'une installation personnalisée), fonctionnant dans le cadre des outils familiers Advanced Container Networking Services. De plus, Microsoft s'assurera que votre instance Cilium est à jour et vous fournira une assistance que vous n'obtiendrez pas avec une instance personnalisée. 

Même si vous êtes peu susceptible d'interagir directement avec le matériel Azure, bon nombre des innovations de la plateforme dont parle Russinovich dépendent des changements d'infrastructure qu'il a évoqués lors d'une précédente session Ignite, en particulier sur des éléments tels que l'accélérateur réseau dans Azure Boost. Cela sous-tend les mises à niveau d'Azure Container Storage, qui fonctionne à la fois avec le stockage NVMe local et le stockage distant à l'aide des services de stockage Azure. L'une des mises à niveau consiste en un cache distribué qui permet à un cluster Kubernetes de partager des données à l'aide du stockage local plutôt que de les télécharger vers chaque pod à chaque fois que vous devez les utiliser, un problème qui devient de plus en plus important pour les applications qui lancent de nouveaux pods et nœuds pour gérer l'inférence. Grâce au cache, un téléchargement qui pouvait prendre plusieurs minutes est désormais un accès à un fichier local qui ne prend que quelques secondes. 

Sécurisation des conteneurs au niveau de l'OS 

Il est important de rappeler qu'Azure (et d'autres hyperscalers) n'a pas pour vocation de fournir aux utilisateurs leurs propres serveurs ; son modèle utilise des machines virtuelles et plusieurs locataires afin d'exploiter au maximum son matériel. Cette approche exige une attention particulière à la sécurité, au renforcement des images et à l'utilisation de l'isolation pour séparer les infrastructures virtuelles. Dans le monde des conteneurs serverless, en particulier avec les fonctionnalités de virtualisation directe, nous devons verrouiller encore plus qu'avec une machine virtuelle, car les conteneurs hébergés par ACI partagent désormais le même système d'exploitation hôte. Les politiques déclaratives permettent à Azure de verrouiller les fonctionnalités des conteneurs afin de réduire le risque que des images de conteneurs compromises affectent d'autres utilisateurs. Dans le même temps, il s'efforce de sécuriser le système d'exploitation hôte sous-jacent, qui pour ACI est Linux. SELinux permet à Microsoft de verrouiller cette image, fournissant ainsi un système d'exploitation hôte immuable. Cependant, ces politiques SELinux ne franchissent pas la frontière des conteneurs, laissant leur espace utilisateur vulnérable. 

Microsoft a ajouté des fonctionnalités à Linux qui permettent de vérifier le code exécuté dans un conteneur. La fonctionnalité Integrity Policy Enforcement fait désormais partie de ce que Microsoft appelle OS Guard, avec une autre fonctionnalité : dm-verity. Device-mapper-verity est un moyen de fournir un hachage distribué des conteneurs dans un registre et des couches qui composent un conteneur, depuis l'image du système d'exploitation jusqu'à vos binaires. Cela vous permet de signer tous les composants d'un conteneur et d'utiliser OS Guard pour bloquer les conteneurs qui ne sont pas signés et fiables. 

Fournir des correctifs sécurisés à chaud 

Une approche de la sécurité basée sur des politiques permet de remédier rapidement aux problèmes. Si, par exemple, une couche de conteneur commune présente une vulnérabilité, vous pouvez créer et vérifier une couche de correctif et la déployer rapidement. Il n'est pas nécessaire de corriger tout le contenu du conteneur, mais uniquement les composants concernés. Microsoft applique cette approche depuis un certain temps déjà aux fonctionnalités du système d'exploitation dans le cadre de son projet interne Project Copacetic, et étend désormais ce processus aux environnements d'exécution et bibliothèques courants, en créant des correctifs avec des packages mis à jour pour des outils tels que Python. Comme cette approche est open source, Microsoft s'efforce d'intégrer dm-verity dans le noyau Linux. Vous pouvez considérer cela comme un moyen de déployer des correctifs sur les conteneurs entre la création de nouvelles images immuables, en remplaçant rapidement le code problématique et en maintenant vos applications en fonctionnement pendant que vous créez, testez et vérifiez votre prochaine version. M. Russinovich décrit cela comme le déploiement d'un « correctif en quelques heures au lieu de plusieurs jours ». 

Fournir les outils nécessaires pour sécuriser la livraison des applications n'est qu'une partie de la stratégie de Microsoft visant à définir les conteneurs comme le package standard pour les applications Azure. Fournir de meilleurs moyens de faire évoluer les flottes de conteneurs est une autre exigence clé, tout comme l'amélioration des réseaux. L'intérêt de M. Russinovich pour les conteneurs est logique, car ils intègrent tous les composants nécessaires d'un service et les exécutent en toute sécurité à grande échelle. Avec les nouveaux services logiciels s'appuyant sur les améliorations apportées à l'infrastructure Azure, il est clair que les deux côtés de la plateforme Azure travaillent ensemble pour offrir une vision d'ensemble, dans laquelle nous écrivons du code, le rassemblons et (au-delà d'une configuration de base basée sur des politiques) laissons Azure faire le reste du travail à notre place. Ce n'est pas quelque chose que Microsoft va réaliser du jour au lendemain, mais c'est un avenir qui est en bonne voie, et auquel nous devons nous préparer.